1. Field of the Invention
The invention relates generally to hardware design and verification. More specifically, the invention relates to a method and system for verifying functionality of hardware components that move data between nodes in a computer (or network) system.
2. Background Art
A bus bridge is one example of a hardware component that moves data between nodes in a computer system. A bus bridge connects two distinct buses so that agents on one bus can contact agents on the other bus. The term agent, as used herein, is an entity that operates on a computer bus. Computer systems generally include multiple agents, e.g., processors, memory, hard disks, monitors, network adapters, etc. An agent that initiates a bus transaction is called a master or initiator, and an agent that responds to a bus transaction initiated by a master is called a slave or target. There may be several masters on a bus and one or more masters may request a bus transaction at any given time. Usually, arbitration processes are used to determine the order in which the transactions are processed. Transactions between a master on one bus and a slave on another bus involve the transfer of address and data information over the bus bridge together with exchange of timing and control information for synchronization and specification of the data format. The set of rules governing the bus transaction is called the bus protocol.
A master initiates a bus transaction with a slave by putting an address on the bus. The address is transferred to the other bus over the bus bridge. The slaves connected to the other bus compare this address with their addresses and become connected if a correspondence is found. Once a connection is established between the master and the slave, the master exchanges information with the slave. For a read operation, for example, the slave responds by reading data from the specified address and returning the data to the master. Each transfer of data between the master and the slave is called a bus cycle. A transaction usually takes more than one bus cycle. Each transfer of data between the master and the slave must be synchronized to ensure that the computer system works efficiently. The transfer timing may be fixed, in which case the master assumes that the slave can accept or provide data within a certain time. Alternatively, the transfer timing may be adjusted to the speed of a particular device by a process known as handshaking.
The primary function of the bus bridge is to move data from one bus to the other. To ensure that the bus bridge operates correctly, various schemes are used to verify the functionality of the bus bridge. The verification schemes typically fall under one of two categories: transaction based or memory-image based. Transaction-based verification schemes involve generating packets, i.e., blocks of data, at a source bus, sending the packets over the bus bridge, and checking the packets received at a destination bus. Each packet represents a bus transaction. For simple designs, there should be a one-to-one correspondence between the packets generated at the source bus and the packets received at the destination bus. Thus, finding design bugs such as dropped packets or spurious packets is relatively easy. Also, checking the destination bus as the packets are received as opposed to checking at the end of the test makes it easier to identify the source of the bug.
Transaction-based verification schemes are, however, difficult to implement for complex designs that have inbuilt intelligence and do operations like fragmentation and aggregation, i.e., splitting and joining, of packets. In such complex designs, determining one-to-one correspondence between the packets generated at the source bus and the packets received at the destination bus is not straightforward. For complex designs, memory-image-based verification schemes are preferred. Memory-image-based verification schemes involve associating a memory image with each bus connected to the bus bridge and giving each bus restricted write permissions on the associated memory. Design bugs are found by comparing the memories at the end of the test. This scheme is relatively easy to implement. However, it does not guarantee to find bugs such as dropped packets and spurious packets. In addition, finding the bug at the end of the test makes debugging very difficult.
U.S. Pat. No. 5,937,182 issued to Allingham discloses a verification method for bus bridges. In the verification method, simulated models of the bus bridge, the two buses connected to the bus bridge, and the devices connected to the buses are constructed. Then, an expect buffer is created at a test bench, and a set of events expected to occur during a time frame of interest for the simulation is loaded into the expect buffer. Each time an event occurs, e.g., each time a device connected to one of the buses writes data to a device connected to the other bus, the relevant device model notifies the test bench of a completed event. The test bench then searches the expect buffer for an entry matching the just-completed event. A matching event entry is removed from the expect buffer while the lack of a matching event entry triggers the system to flag the just-completed event as an unexpected event. When the simulation is complete, any remaining entries in the expect buffer are reported as missing events.